ユーザーストーリーマッピング (Patton)
正式タイトル : ユーザーストーリーマッピング
https://images-na.ssl-images-amazon.com/images/I/51MlUN5G99L._SX352_BO1,204,203,200_.jpg
内容メモ
ただし、ソフトウェアシステムが何をすべきかの全体像が見えづらくなった
ストーリーマッピングは、全体像を提供するための技法
機能をひとつずつ作ってソフトウェアをくみ上げるのは妥当だが、ふるまいや製品の全体像の設計でも同じ手法を用いると、フランケンシュタイン的な怪物プログラムが生み出されかねない 本書は、チームのコラボレーション、コミュニケーションのあり方、優れたデザインを作り上げる方法の核心に触れる
優れたチームとダメなチームの重要な違い
まえがき
対象職種
それ以外の全ての人々
0 章 : まず最初に読んでください
この本で最も重要なこと
ストーリーを使う目的は、良いストーリーを書くことではない → 本当の目的は共通理解をつかむこと
要件を形式に落とし込むためのものではないし、ストーリーは要件ではない 製品開発の目標は、製品を作ることではない → 本当のあなたの仕事は世界を変えること
より早く、より多くのソフトウェアを生み出すことではない
やるべきことは要件を満たすことではなく、世界を変えること 議論して共通理解を得た内容をドキュメントに書くことで、共通理解をした当人たちが思い出せる
アジャイルプロセスでもたくさんのメモやスケッチを書く
一番大事なことは思い出せること
世界を変えるということ
本当に欲しいものは成果 (outcome) : 世に出た (come-out) ときに結果として現れるもの 人々が目的を達成するために実際にやり方を変えられたか？ 生活が良くなったか？
ストーリーについて話すときには、誰のためか、なぜなのかも話す
顧客やユーザーが欲しいものを手に入れられない限り、会社も欲しいものを手に入れられない
売上の増加や経営コストの削減、顧客満足度の上昇やマーケットシェアの拡大など
人々の生活をより良いものにすると同時に、会社が健全性を保つ ← インパクト (優れた成果を上げた結果として長期的に起きること) 作るべきものは我々が持っている時間・リソース以上に存在する
1 章 : 全体像
ストーリーがストーリーと呼ばれるゆえんは、何を書くべきかではなく、それをどのように使うべきかだから 話して記録 : ストーリーを話しながら、カードかポストイットに考えていることを書き出して思考を表出化
会話しているときにせっかくのアイデアが蒸発することは避けるべし
他人の話を聞いているときにアイデアを思いつくことがある → 忘れないようにポストイットに書き留める
アウトプットではなく目指したい成果から会話
成果のカードの並び順をあえて適当にすることで、本人に並び替えてもらう (本人が考える優先度を知る)
誰に届けたいかも同様
まずは全体 : ユーザーのある 1 日をイメージして、製品がどう使われるかをストーリーで話す
これにより共通理解を作っていく
1 つのストーリーを掘り下げる前に、まずは全体 : 深さ 1 cm、幅 1 km のことを考える
個々のステップで次のことを考える
ここでユーザーが行うことは具体的には？
他に代替案としてできることは？
何があったら 「これはかっこいい」 と思える？
おかしくなったときにどう対処する？
2 章 作るものを減らすためのプラン
常に、我々が持つリソース (時間や資金など) 以上に作るべきものが存在する
複数チームにまたがる製品のリリースでは、依存関係明確化のためにマップを作る
複数のチームで協働
それにより穴が見つかりやすい (他のチームが担当すると思っていたが浮いていたものや、システム間連携など)
スコープが知らぬ間に増えることはなく、単に理解が進んだだけ (そしてマップ作成で理解が進むことは良いこと)
マップの背骨を見ると、システムに関わる全ての人々が目的達成のために作業をするストーリーが聞こえる
システム内部の機能を決めるときには、まずシステムの外側で起きてほしいことを考える
そのような成果を生み出すリリースを切り出す
マップをスライスに分ける (上下方向に切る)
スライス化は見事なテクニック
左側にスライスごとに期待する成果を記述
カードを適切なスライスに入れていく
これは機能のリストではなく、現実世界でのメリットの羅列
特定の成果に的を絞ることが開発における優先順位付けの秘訣
3 章 より早く学ぶためのプラン
大きなアイデアを前進させるために、まずは会社のオポチュニティ (好機) として扱う
会社の幹部と議論 (大きなアイデアとは何？ 顧客・ユーザーは誰？ なぜ彼らはそれを使いたがる？ なぜ我々が作る？)
社内でこの好機のオーナーになるために、社内の人と共通理解を築く必要
ストーリーについての最初の議論は、オポチュニティの枠組みをつかむためのもの
次に、解決しようとしている問題が本当にあるのか確かめる
顧客・ユーザーと話しながら、新しいソフトウェアを試したらいいと思われる人々 (顧客開発パートナーと言ったりもする) をリスト化していく 学べば学ぶほど最初のオポチュニティは変わっていく
自分のソリューションが有用で価値あるものかどうか知るために、プロトタイプを作ってユーザーに見てもらう そのあとは、minimum 未満で viable ではないが、対象の顧客やユーザーの問題を解決できるかもしれない製品を作り、開発パートナーになってもらった顧客やユーザーに送り届ける
実際に使ってもらえるか？
Minimum で Viable になるまでリリースを繰り返す
開発パートナーの人たちが、自発的に他の人に薦めるようになったら MVP であると言える
全てのリリースを実験として扱い、何を学びたいかを忘れないように
我々の目標は、何かを作ることではなく、正しいものを作っているかどうかを学ぶこと
学ぶことが目標であれば、構築を最小限にして学ぶ必要があるものに注力できる
4 章 時間どおりに終わらせるためのプラン
マップは、会話の助けに必要な分だけ作ればよい (製品全体のマップを作る必要はない)
最良の見積りは、自分が何を見積もっているのかを本当に理解している開発者から出てくる
共通理解の構築が見積りのカギ！
少しずつ構築するための計画
リリースできる最小限の構成でもそれなりの大きさがあれば、例えば 3 つのスライスに分ける
2. もっと良くする
ここで、プロトタイプではわからなかったことなどがわかったりする
3. リリースできるように磨けるだけ磨ける
上記の 3 つスライスはリリースのためのものではないので、スライスごとのリリースはしない
見積りはあくまで予測でしかないが、実績は測定できる
測定することで見積りを正確なものに近づけることができる
大きなものをスライスすることで測定する機会が増える
ストーリーマップにリスクストーリーを組み込んだ事例
リスクや不確実性のために必要な時間を計画に組み込むように
リスクを測定してまなびをステークホルダーに共有する方法としてリスクバーンダウンチャートも得られた
芸術家が作品を作成するようにソフトウェアを開発する
どんなに小さな製品や機能でも、リリースバックログを 3 つに分ける
序盤戦 : 製品が最初から最後まで動くことを確認
製品全般に関わる基本的機能や基本的なユーザー行動に注力
技術的に難しい部分やリスクの高い部分も
中盤戦 : 仕上げを埋めていく
終盤戦 : リリースを磨く
全てはリスク対策 : 製品が間違っていると後から判明するリスクや、技術的リスク
5 章 あなたはもうやり方を知っている
ソフトウェアを使う人が目標達成のためにしているタスクをユーザータスクという 例えば 「朝食を作る」 みたいな粒度で書くべきであり、「コップにジュースを注ぐ」 みたいな粒度では書かない
まず思いつくタスクでナラティブフローを作った後、さらに追加で例外時のタスクや理想の状態におけるタスクを追加していく
このとき、似たようなタスクは同じ列に入れていく
まとまって発生するように見えるストーリーをまとめる (アクティビティという) アクティビティのポストイットの並びがバックボーンになる
スライスを使って、特定の目標を達成するためのタスクと細部を明らかにする
例 : 寝坊して急いで家を出なければならないときのように、急ぎの場合でもやる必要があるものとそうでないものを分ける
上に必須のものを残して、省略できるものを下に移動する
このとき、アクティビティ自体は (上のスライスからはタスクが消えたとしても) 残しておく
将来のことをマッピングした将来マップと現在のことをマッピングする現在マップがあるが、コンセプトは同じ
6 章 ストーリーについての本当のストーリー
要件記述に関する問題
同じドキュメントを見ても人々が異なる理解をする
間違ったことを正確に記述していることがある
何が必要かは書かれているが、なぜ必要かが書かれていない
単純に、完璧なドキュメントを必死に書くことをやめて、ストーリーを語るようにした
ストーリーの思想は語ること : 聞き手の心にエネルギーや興味、ビジョンを生み出す
7 章 より良いストーリーテリングのために
Connextra で生まれたテンプレート : <ユーザータイプ> として、私は <これこれの結果を得る> ために、<これこれ> をしたい 誰が、何を、なぜ、を考えられるように
誰と会話すればいいかがわかるようにする
テンプレートゾンビにはならないように (テンプレートに従っていなくても、ストーリーはストーリー) テンプレートはあくまで練習用であって、難しい領域では最良の選択ではない
リアルに迫るために
「誰が」 の解像度を上げる (「ユーザー」 では広すぎる)
ユーザーのタスクから考えられないもの (権限チェックなど、ユーザーが意図的に選択しないもの) については、ユーザーではなくサービスやシステム目線で考える
「なぜ」 は階層構造になっていることが多いので、深く掘り下げること
ソフトウェアの外部について話す (どこで、いつ、使われるのか？ どれぐらいの頻度で？ 利用時の状況は？)
うまくいかない可能性について話す
疑問や暗黙の仮定について話す
より良い解決法について話す
How について語る : why、what、how のいずれもバランスがとられて話されるべき
how が要件になってしまうと良くないが、そうでなければ how を話さないと解決策のコストを考えられない
期間について語る
8 章 カードに書かれていることがすべてではない
ストーリーカードは図書館の目録カードのようなもの : 全ての情報がそこにあるわけではない
壁に情報があるとコラボレーションが生まれる
9 章 カードは始まりにすぎない
ストーリーの詳細を他の誰かに渡して作ってもらおうとしても決してうまくいかない
チームに属する誰もがどのストーリーをも拾えるように、全員がどのストーリーについての会話にも参加する、というのはバッドプラクティス
効果的な議論や意思決定は 2 人から 5 人が適している
完成したものの品質について話すときの 3 つの観点
コードの品質
変更が必要な場合は、以下の 2 つを切り離して考えること
合意したとおりのものを作ったか？
合意したものを作ったうえで、その完成品を見た結果、変更を加えるべきか？
作ったうえで学習することを織り込んでおく
ストーリーをバックログに入れるときには、最初からそれを変更することと、その変更をさらに変更することを織り込む
『動くソフトウェア (または包括的なドキュメント) よりも、「検証された学習」 を』 学ぶために計画し、計画するために学ぶ
10 章 ケーキのようにストーリーを焼く
ストーリーが表すソリューションがコストがかかりすぎるなら、目標達成に近づく別のものを検討
コストに問題がなくても大規模であれば、早い段階で進行状況を評価したり確認できる小さなものに分解
11 章 岩を砕いていく
ストーリーの適正なサイズ
ビジネス視点 : 会社が業績を上げる役に立つ粒度
ユーザー視点 : ニーズを満たす
開発チーム視点 : ビルドやテストに数日しかかからない粒度
ストーリーを砕くには会話がいちばん
エピックは大きすぎるが、それはあくまで開発チーム視点であり、ビジネスや顧客、ユーザー視点だと適正なサイズ グループにまとめると便利な一連のストーリーをテーマという用語を使おう 12 章 岩を砕く人
ストーリーを書き、ストーリーについての会話を主催する責任者がひとりだけ、というのは破綻する
一人では足りない
プロダクトオーナーは製品とチーム全体が同じ方向に向かって動くようにする重要なリーダー
逆に、委員会による設計もよくない (変な妥協をしたり、あるいはあらゆることをやったりする)
ウェイターと客の関係ではなく、医者と患者の関係に近づける
IT システム以外をプロダクトとして扱う事業 (銀行など) の場合、プロダクトマネジャーは銀行口座や信用商品などを対象とする プロデューサーと音楽バンドのような関係 (音楽バンドの成功のためにプロデューサーは尽力する) を目指すべし
13 章 オポチュニティから始める
14 章 ディスカバリーを介して共通理解を築く
15 章 ディスカバリーによる検証された学習 (Validated Learning)
ソリューションに興味を持つ顧客が見つかったかどうか継続的にチェック
頭のなかにあるソリューションが、彼らが購入し、使用し、他の人に薦めるようなものになっているかどうかチェックする
この学習サイクルを短縮する
目標は、できる限り早いうちに何かを学ぶこと
16 章 リファイン、定義、構築
17 章 ストーリーは実際にはアステロイドに似ている
ストーリーの分解を全部どんどん小さくすると不必要な複雑さに埋もれてしまう
段階に応じた目的を意識
1. オポチュニティ : ストーリーは誰のため？ 彼らが解決したい問題は何？ 会社の事業戦略に沿っている？ 3. 開発戦略のプランニング : リスクはどこにある？ 最も多くのことを学ぶにはどうすればいい？
4. 次の開発サイクルのプランニング : 何を構築するか決めて、完成したことを確認する方法について意見を一致
18 章 構築するすべてのものから学ぶ
19 章 終わり？ それとも――